做智能制造车间数字化这些年，我们团队没少在产线边上吃灰。早些年给客户上MES系统，标配就是一人一把工业PDA，看着威风，其实毛病一大堆：价格贵、电池衰得快、屏幕小得看不清批次号，最要命的是系统封闭，想跟新业务打通得找原厂二次开发，报价的狠劲儿能让人倒吸凉气。
这两年不少客户跑来问，说现在工人自己手机像素都逆天了，能不能用微信小程序扫条码，把那堆吃灰的PDA淘汰了？我们的回答很干脆：能，但千万别以为接个普通HTTP接口让小程序调一下就完事了。在智能制造车间里，扫码数据的传输如果掉出低延时区间，产线节拍分分钟给你脸色看。
手机当扫码枪，核心矛盾从来不是识别率。现在手机摄像头配合小程序里的ZXing或者自研CV算法，扫个污损的DM码比老式红光枪还利索。真正的坑在“传”这个字上。车间里满地金属机床，WiFi信号反射多径效应严重，AP之间漫游切换丢包是常态。我们实测过，某家电工厂老车间里，手机小程序走普通公网链路到云端MES，一次扫码到状态回执平均要800毫秒以上，工人扫完码得举着手机等“成功”提示，手脚慢的接连被后道工序催，老师傅们骂骂咧咧差点把手机摔了。
我们给这类场景攒下的低延时方案，得从网络、传输、应用三层一起动刀。
网络侧，我们绝不会让手机直接漫无目的连车间WiFi。在部署上，我们要求和客户IT部门配合，把扫码业务划到独立的SSID，并且根据产线布局做AP信道复用优化，避免2.4G拥堵。更关键的是，在车间本地柜子里塞进我们的边缘计算网关，手机小程序通过内网直连边缘节点，而不是绕到外网云端。这招下去，物理网络RTT直接从上百毫秒砍到个位数。
传输协议选型上，很多同行爱用小程序WebSocket连个Spring Boot就觉得高明了，其实在弱网车间里不够稳。我们采用MQTT over WebSocket，并且由边缘网关做协议终结与桥接。MQTT的QoS1保证至少送达一次，配合会话保持，手机进电梯或拐角短暂掉线，重连后消息补发，扫码记录绝不丢。同时我们给不同业务打优先级标签：物料上线扫码标记为高优，立马推送；盘点类低频操作走普通队列。这样核心流程的端到端延时牢牢锁在90到120毫秒。
当然，微信小程序本身对后台网络连接有不少框框，比如切后台后WebSocket容易断。我们就在小程序里做了前台高频心跳，并结合车间部署的蓝牙信标辅助定位，工人走到哪段产线，就由对应区域的边缘网关主动唤醒重连。这细节不扒拉清楚，到了现场准掉链子。
应用层的小程序端，我们写了本地可靠队列。工人“滴”一声扫完，数据先落手机本地Storage，立刻反馈UI成功，后台默默异步上报。万一边缘节点临时维护，数据在手机里攒着，恢复后自动同步。服务端接到消息做幂等校验，防止重复扫码造成入库翻倍——这事儿在汽车总装车间出过一次事，后来我们加了基于设备号 时间戳的防重锁，就再没犯过。
去年我们在一家新能源电池模组工厂落地这套架构，替代了他们六百把老PDA。实测下来，扫码到MES状态回写平均延时压到了95毫秒，比他们之前用工业扫码枪的无线基座还快一截。IT部门算过账，光硬件利旧和运维省下的钱，两年够把全厂手机防爆壳配齐。
说到底，手机变扫码枪不是玩噱头，背后考验的是软件系统公司对车间物理环境和通信协议栈的深度打磨。谁能把那几百毫秒的延迟啃下来，谁才配谈智能制造的“轻量化采集”。
微信号：18581869297
